The World Wide Web (www or web) provides a cost-effective way for enterprises to publish and distribute documents that are formatted in Hyper Text Markup Language (HTML). By publishing HTML documents in a centralized web server, enterprises can communicate with people all over the world via the ubiquitous public Internet and the universally available web browsers.
As the web grows, enterprises are looking beyond just using the web for delivering HTML documents. Enterprises and software vendors are looking to deliver business applications over the web and to perform distributed computing over the web. Distributed computing describes a type of computing in which different components and objects comprising an application can be located on different computers connected to a network. For example, a word processing application might consist of an editor component on one computer, a spell-checker object on a second computer, and a thesaurus on a third computer. In some distributed computing systems, each of the three computers could even be running a different operating system.
The web architecture could provide the same benefits for business applications as it does for web documents. These benefits include:                a) Centralized management: applications and documents can be centrally managed on the server side, giving enterprises great control of security, business logic and data.        b) Centralized deployment: enterprises do not need to touch thousands of client computers to update applications and documents, i.e., changes on the server can instantly reach all users.        c) Universal delivery: applications and documents can reside in a central server and can be delivered to any client computer that has a web browser and an Internet connection, both of which are universally available.        
However, the web was originally designed for browsing linked documents and not for delivering business applications. Referring to FIG. 1, the web infrastructure 100 includes an application server 105 for running application code 106, a web server 110 that delivers HTML documents generated by the application code 106, and a web browser 130 residing in a client machine 120 and displaying HTML documents in a “click and refresh” fashion. Application code 106 is usually written using a programming language including among others C, C++, C#, Java, Javascript, VBScript, ActionScript, VisualBasic or some proprietary language. The web browser 130 communicates with the web server 110 via a request/respond communication model 140. In this request/respond communication model 140 a user places a request for a specific web page through the web browser 130 and the web browser 130 sends the request to the web server 110 using a Hyper Text Transfer Protocol (HTTP) (142). The web server 110 receives the request and transfers it to the application server 105. In the application server 105 the application code 106 processes the request and generate a response that comprises HTML documents. Next, the web server 110 responds to the request by sending the generated HTML documents to the web browser 130 (144). This web infrastructure 100 is “stateless”, i.e., neither the web server 110 nor the web browser 130 maintains the state of the application. The state of an application is a snapshot of all the program objects, variables and resources at each particular moment, the value of the variables, the relationship between different program objects, and the conditions of different resources. The state of an application changes and evolves as the application runs. For example, when a user is shopping at the website of Amazon.com, the state of the shopping application includes information including among others the current user name, number of items in the shopping cart and price of each item.
As was mentioned above, in the web infrastructure 100 of FIG. 1 the state of the application is not maintained either the client machine 120 or the web server 110. The client machine 120 merely displays HTML documents and only maintains the state information of the current documents. When a new document is loaded, the state information of the previous document is discarded and replaced by the new document's state information. State information of the previous document is lost.
For example, referring to FIG. 1A, a first markup document 142, page1.xml, contains code that will display in the client machine 120 a button 150 with text “This is a line of Text”. A second markup document 146, page2.xml, contains code that will change the button's 150 background color to be gray, shown as button 152. The corresponding object oriented representations 144, 148 of the first and second markup documents 142, 146, respectively, are also shown in FIG. 1A. When the client machine 120 downloads the first markup document 142, the text “This is a line of Text” 150 is displayed in the client machine 120. The application state at this moment, shown as 154, contains all the information of the first markup document 142. Following the display of the first markup document 142, the client machine 120 downloads the second markup document 146, whereby the application state at this moment, shown as 156, discards the state of the first markup document 142 and contains the state of the second markup document only. As a result, the client machine displays a blank gray button 152 wherein the text “This is a line of Text” is gone even though button 152 is still the same button as button 150.
This “stateless” nature of today's web infrastructure 100 has limited the applicability of the web for delivering business application. Business applications are inherently “stateful”. For example, the response to a user's click typically depends not only on what the user clicked, but also on the state of the application, such as the history of the user's interactions, the value of a form, or even the network connectivity. Software developers today have to write an extensive amount of code to maintain such state information on the server side, typically inside an application server. The application code needs to deal not only with how to generate responses to client requests but also with how to maintain and manage the application state. In the web infrastructure 100 of FIG. 1, the state of an application is maintained by application code running inside the application server 105. Such extensive work required for maintaining application state on the server side. This increases both the development cost and the application maintenance cost.
Furthermore, an entire new markup document has to be sent to the client machine upon every request/response, even if the new markup document contains only small changes to the previous markup document. A typical markup document can have a size of 10 kilobytes to several hundred kilobytes. Transmitting such documents consumes a lot of network bandwidth and slows down the application responsiveness.
Another problem for the delivery of business applications over the current “stateless” web infrastructure is the fact that network connections may not always be available. Because no state is maintained on the client-side, web applications built on the current infrastructure are unavailable if the network connection is not available. This possibility of a “down time” is not acceptable for business applications. As a result, developers have to write client and/or server applications to support such offline operation capabilities.
The “stateless” Hyper Text Transfer Protocol (HTTP) request/response model 140 does not enable real-time, bi-directional two way communications. This HTTP communication model 140 supports only “client pull” communications, in which the user has to send a request to the server in order to get new data. A lot of business applications require “stateful” connections that are persistent, through which the web server can send real-time data updates to different client machines, i.e., a “server push” model. For example, a stock portfolio management application requires real time stock data. Whenever the stock price changes, the user needs to receive the new price immediately. As a result, developers have to write a lot of code to enable “server push”, where firewall issues and other security related issues are very challenging and expensive to deal with. In summary, the challenges of enabling bi-directional communications over the Internet are three folds:
a) The Internet as network infrastructure is capable of transmitting any kind of messages. However, a lot of enterprise environments allow only HTTP traffic due to security concerns. So if the messages are not transmitted via the HTTP protocol, such messages may not be able to reach the destination due to various firewall policies.
b) HTTP is designed to function as one-way, request/response model from a web browser to a web server. A web browser will open a connection to an HTTP web server through which it sends the request. The HTTP web server responds to this request, sends the response back to the web browser, and then closes the connection. Though HTTP 1.1 added features like “Keep-Alive” that can make the connection open for a period of time during which multiple request/response pairs can be transported through the same connection, this feature is not universally supported by all web browsers or web servers. Even if it is supported by the web browser and the HTTP web server, this “Keep-Alive” connection is only available to the HTTP web server internally for sending responses to client requests. Application code running inside an application server can not use this connection for doing “server push”.
c) To enable bi-directional communications over HTTP, there are various HTTP tunneling techniques available. They typically require specially built client or server software for maintaining the persistent connection, through which messages are wrapped inside the HTTP protocol for transport purpose. Such techniques introduce extra costs and potential security problems. For example, they typically require extra server software that accepts and manages persistent connections through a port other than the standard HTTP server port (port 80). This breaks the server side firewall and has significant potential security risks.
There is no current method that can provide reliable “server push” capability to application code running inside a standard application server without changing client side or server side configurations.
Furthermore, the HTTP communication model is unreliable because messages can get lost due to various network problems. HTTP does not have a way to guarantee message delivery. Losing messages may be acceptable for web browsing but unacceptable for running business applications. As a result, enterprises have to spend a lot of extra resources to solve this problem for their important applications.
In summary, the web architecture could potentially bring great benefits to business applications, such as centralized management, universal delivery and universal deployment. However, the “stateless” nature of the web architecture has limited the usage of the web for business critical applications. In order to overcome these limitations, developers have to write a lot of complex code that significantly increases development costs as well as application management and maintenance costs. Despite some costly development efforts, web-based applications perform clumsy and consume excessive network bandwidth, frequently disappointing end users. Therefore, there is a need for a “stateful” web-based delivery of business applications that overcomes the above mentioned limitations.